Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1991/91-09

Text File | 1995-12-31 | 96KB | 2,816 lines

Path: ucivax!gateway
From: [e-mail] (Kerry 'UPE' Cianos)
Subject: EditText solved
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 15
Date: 1 Sep 91 04:55:25 GMT
X-Envelope-to: [e-mail]


  Welp, thanks to the people who sent me mail on my problem.  Since I'm so
new to Mac programming that I overlooked a simple problem.  I was sitting
reading IM I when it says I need to check for the command key if I have
items that use it... well, I just stuck two lines of code in to check for
the Return key instead and bingo!  Problem solved!!  Sometimes you just
gotta take a step back ...

     Kerry

  ------------------------------------------------------------------------
  Kerry Cianos, President                PS/2 = PS divided by 2 =
  Impress Technologies                   half a computer, thats ok, OS/2
  Email : [e-mail]           is only half an operating system!











Path: ucivax!gateway
From: [e-mail]
Subject: Re: EditText Item for Modeless
Message-ID: <[e-mail]>
In-Reply-To: Your message of 31 Aug 91 20:09:39 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 66
Date: 2 Sep 91 10:38:31 GMT


> You should be able to type in
>the number and hit return, then other fields in the dialog would be updated
>accordingly.  I've made a modeless dialog, with a TextEdit item.  But
>again, when I hit return it actually does a CR.

I made a modeless dialog for some year(s) ago. To intercept the returnkey and
all sort of arrowkeys I checked each keyDownEvent before sending it to
DialogSelect(). Here you could also check if the character is a number.

I've included the EventLoop below. Note: this is not an example of good
programming style, but at least it works


void EventLoop() {
    extern EventRecord    theEvent;
    extern int itemHit,itemLast;
    extern DialogPtr theDialog;
    register char thechar;
    while (itemHit != 22) {
    SystemTask();
    GetNextEvent(everyEvent,& theEvent);

    if (theEvent.what==keyDown||theEvent.what==autoKey){
        thechar=theEvent.message & charCodeMask;
        if  (thechar ==13){
            itemHit=1; /*interception of returnkey*/
            HandleConjDialog();}
        else if ((theEvent.modifiers & cmdKey)!=0)
            doMenu(MenuKey(thechar));
        else if (thechar==30){    /*arrowkey up*/
            itemHit=(itemLast-1);
            if (itemHit==1) itemHit=16;
            HandleConjDialog();}
        else if (thechar==31){    /*arrowkey down*/
            itemHit=(itemLast+1);
            if (itemHit==17) itemHit=2;
            HandleConjDialog();}
        else{
            DialogSelect(&theEvent, &theDialog, &itemHit);
            HandleConjDialog();}
        }

     else if (IsDialogEvent(&theEvent)) {
        if (DialogSelect(&theEvent, &theDialog, &itemHit)) {
            HandleConjDialog();    }
              }
     else {
          if (theEvent.what==mouseDown)
          HandleMouseDown(&theEvent);
            /* Handle non-dialog events */
         }
     }
}




       /Olle


------------------------------------------------------------
Olle Furberg                       Internet: [e-mail]
Satellitbild in Kiruna             Phone: [phone]
Swedish Space Corporation          Fax: [phone]
------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail] (David Sugar)
Subject: Gestalt/TrapAvailable??
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 3 Sep 91 04:54:31 GMT


  I'm using Gestalt calls to check for system stats, but I need to know
wether Gestalt is actually there before I call it...
  In IM VI it says to call TrapAvailable, but Think C doesn't seem to
like that call.  Is there something I'm missing?  I am seting
_Gestalt to 0xA1AD and the calling TrapAbailable(_Gestalt); just like
in IM VI page 3-32.  Is there an include that I might be missing or
something.  I'm using Think C 4.0.5 and have the Gestalt include
that I ftp'ed from ics.uci.edu...

Dave Sugar
[e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Gestalt/TrapAvailable??
Message-ID: <[e-mail]>
In-Reply-To: Your message of "03 Sep 91 04:54:31 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 3 Sep 91 06:53:21 GMT

> From:    David Sugar <[e-mail]>
> To:      [e-mail]
>
>  In IM VI it says to call TrapAvailable, but Think C doesn't seem to
>like that call.  Is there something I'm missing?  I am seting
>_Gestalt to 0xA1AD and the calling TrapAbailable(_Gestalt); just like
>in IM VI page 3-32.  Is there an include that I might be missing or
>something.  I'm using Think C 4.0.5 and have the Gestalt include
>that I ftp'ed from ics.uci.edu...

Check page 3-8 of IM VI for the source code to TrapAvailable.
(Or there are a few other versions floating around...)
  --dave koziol










Path: ucivax!gateway
From: [e-mail] ("Gary T. Czychi")
Subject: Re: TCL: Changing TextEdit fields on 'TAB'?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: THINK-C
Lines: 47
Date: 3 Sep 91 19:02:19 GMT
X-Envelope-to: [e-mail]


Thanks a lot for the two tips I got (from Phil Shapiro and Larry
Watanabe), but somehow it will not work. I still have problems with
the gGopher:


I wrote:

 >>  From: "Gary T. Czychi" <[e-mail]>
 >>  In my AppMaker generated code for my main window (CMainWindow)
 >>  which is a Subclass of CWindow, I have defined several TextEdit
 >>  fields.
 >>
 >>  Now, I want to jump from field to field when the user types a 'TAB'
 >>  or a 'CR'.


[e-mail] (Phil Shapiro) writes:

 > If you want to modify the behavior of the tab key, you'll have to
 > subclass the CEditText class to special-case the tab key.

ok, I did that.


[e-mail], (Larry Watanabe) writes:

 > You have to make sure that gGopher is set so that the mainwindow
 > will get keydown events. Also, any gGophers have to pass the
 > keydown event upwards if they get it.

I really would like to do that, if I only knew how. I read the
(sparse) OO manual several times now, but that didn't help. Sorry.
I simply don't know how to set the gGopher and where.


Please help,

  Gary

    Gary T. Czychi          University of St.Gallen

       [e-mail] (preferred host)
         czychi at csghsg52   (=bitnet)
           [e-mail]
             Switzerland
              -










Path: ucivax!gateway
From: [e-mail] ("Matthew T. Russotto")
Subject: Re:  Gestalt/TrapAvailable??
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 4 Sep 91 01:12:20 GMT

TrapAvailable is a macro, it compares the trap address of Unimplemented (A89F)
with the trap number.  If they are not equal, the trap is available.










Path: ucivax!gateway
From: [e-mail]
Subject: disabled menu items, and the meaning of life
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 47
Date: 4 Sep 91 16:20:04 GMT


hi all,


i've had quite the lesson this week.  as you read this,
see if you have a reasonable answer to the question
"what are disabled menu items for?".

first experience:  for whatever reason, i chose the
disabled "Open Selection" menu item in Think C 5.
no selection was chosen, just a friendly blinking
cursor.  so Think churns for a moment and tells me
that "file "" not found".  this only works when using
the mouse to select the menu item, not command-D.  (it
also works in Think C 4.)  why does Think allow you to
choose a disabled menu item?

next experience:  now i'm curious.  while in the finder
(7.0), all windows closed and no items on the desktop
selected, the "view" menu and all of its items are dimmed.
i have left a few straggling icons on the desktop, but
no windows.  so, with the mouse i choose "by name" from
the disabled menu.  all i can say is, well, try it and
tell me it ain't a bug.  not only is the disabled menu item
usable, but it does wrong things to the screen.  all of the
"view" menu items work similarly.

by this time i've come to question all that i hold sacred.
what really are disabled menu items for?  at the state of
my current project, i have so many bugs that i just might
take them all and give them disabled menu items!

final experience:  i'm running a version of my project which
was compiled with Think C 4 and TCL 1.0 (it'll be weeks
before it runs smoothly with 5.0 and 1.1).  for the same
reasons of disbelieving curiosity i choose a menu item which
i disable via gBartender->DisableCmd().  need i say more?
i was treated to an error which i had tried to make impossible
by following both apple's and Think's guidelines.

WHAT IS GOING ON HERE?????

i wish i were less angry about this.

:jeff bellsey
[e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: Floating Windows vs Windows
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 4 Sep 91 17:34:53 GMT



I have what may be a couple of  FAQ. Im new to the Mac programming
environment.


What is the difference between floating windows and
normal windows? When they must be used? Is there a
speed/memory factor that will make choose one over another.


If you know C well and have never programmed on the Mac
would you recommend using TCL or write code directly in C.
TCL  seems to make life easier however it is kind of a
Toolbox on top of the MAc Toolbox. Would it be reasonable
to learn the MAC Toolbox first writing code in C and then
go to TCL or do it directly in TCL?

Any comments along these lines are appreciated.

Thanks.

[e-mail]














Path: ucivax!gateway
From: [e-mail] (Wolfgang Naegeli)
Subject: Re: disabled menu items, and
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 38
Date: 4 Sep 91 20:21:44 GMT

        Reply to:   RE>disabled menu items, and th
[e-mail] writes:

> while in the finder
> (7.0), all windows closed and no items on the desktop
> selected, the "view" menu and all of its items are dimmed.
> i have left a few straggling icons on the desktop, but
> no windows.  so, with the mouse i choose "by name" from
> the disabled menu.  all i can say is, well, try it and
> tell me it ain't a bug.  not only is the disabled menu item
> usable, but it does wrong things to the screen.  all of the
> "view" menu items work similarly.

You certainly have discovered an interesting "feature."
It doesn't matter whether you have folder or application windows open.
The dimmed list-view selections treat the entire desktop as a folder window.
The first line of the list, however, overwrites the header.

The file list is fully functional, you can edit file names, doubleclick icons,
and even use the hierarchical folder triangles (and they give you a white
background for the exploded part of the list!)

It looks a little messy, but it might be usefule for people who have lots of
stuff on the desktop. Being able to look at it by name, date, or size, etc. may
come in handy. I'd recommend MasterFinder for that, but if you don't want to
spend the money...

The one thing that I find irritating about this "feature" however, is that when
you select "by icon" again, not all of the icons go back to their original
location, at least not on the virtual part of my screen.

Wolfgang N. Naegeli
University of Tennessee & Oak Ridge National Laboratory
Internet: [e-mail]  (best)       Bitnet: wnn@ornlstc
QuickMail (QM-QM): Wolfgang Naegeli @ 615-574-4510
Phone: [phone]       Fax: [phone] (OrchidFax)












Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: disabled menu items, and the meaning of life
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "[e-mail]" at Sep 4, 91 4:20 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 16
Date: 4 Sep 91 21:08:54 GMT

jeff bellsey ([e-mail]) writes:

[complaints about being able to select disabled menus]

You aren't by any chance running Magic Apple, are you? Magic Apple, that
mis-released copy of the Hand Off II utility Super Menu displayed exactly
this behavior. Disabled menu items do not return the same way that enabled
ones do when MenuSelect is not patched by a poor utility.

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet/ARPAnet/EDUnet  : [e-mail]
BITNET (if no other way) : FREE0285@UIUCVMD










Path: ucivax!gateway
From: [e-mail] (Daniel Segel)
Subject: Disabled Menu Items
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 4 Sep 91 23:30:25 GMT

Any chance you guys are running Magic Apple (part of the beta version of HandOff
that does the Heirarchical Apple Menus), the Extension that was floating around
a month or two ago?

Magic Apple lets you select disabled menu items.

daniel s.

________________________________________________________________________________
Daniel A. Segel           |   Storage Dimensions, Inc.  |  "That's funny,
[e-mail]         |        408/879-0300         |   it works here..."
                          | Macintosh Technical Support |
________________________________________________________________________________










Path: ucivax!gateway
From: [e-mail] (Daniel Edward Rudman)
Subject: Re: disabled menu items, and the meaning of life
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 65
Date: 4 Sep 91 23:42:54 GMT

    From [e-mail] Wed Sep  4 16:45:14 1991
    Received: from caen.engin.umich.edu by mondo.engin.umich.edu (NeXT-1.0 (From Sendmail 5.52)/mondo-1.0)
        id AA02587; Wed, 4 Sep 91 16:45:09 GMT-0500
    Received: from ics.uci.edu by caen.engin.umich.edu (5.64/1.35)
        id 53c895e75.001024b; Wed, 4 Sep 91 16:39:19 -0400
    Received: by ics.uci.edu id aa05065; 4 Sep 91 9:24 PDT
    Received: from ics.uci.edu by ics.uci.edu id aa04180; 4 Sep 91 9:23 PDT
    Received: from USENET by ics.uci.edu id aa04124; 4 Sep 91 9:20 PDT
    From: [e-mail]
    Subject: disabled menu items, and the meaning of life
    Message-Id: <[e-mail]>
    Newsgroups: fa.think-c
    Date: 4 Sep 91 16:20:04 GMT
    To: [e-mail]
    Status: O


    hi all,


    i've had quite the lesson this week.  as you read this,
    see if you have a reasonable answer to the question
    "what are disabled menu items for?".

    first experience:  for whatever reason, i chose the
    disabled "Open Selection" menu item in Think C 5.
    no selection was chosen, just a friendly blinking
    cursor.  so Think churns for a moment and tells me
    that "file "" not found".  this only works when using
    the mouse to select the menu item, not command-D.  (it
    also works in Think C 4.)  why does Think allow you to
    choose a disabled menu item?

    next experience:  now i'm curious.  while in the finder
    (7.0), all windows closed and no items on the desktop
    selected, the "view" menu and all of its items are dimmed.
    i have left a few straggling icons on the desktop, but
    no windows.  so, with the mouse i choose "by name" from
    the disabled menu.  all i can say is, well, try it and
    tell me it ain't a bug.  not only is the disabled menu item
    usable, but it does wrong things to the screen.  all of the
    "view" menu items work similarly.

    by this time i've come to question all that i hold sacred.
    what really are disabled menu items for?  at the state of
    my current project, i have so many bugs that i just might
    take them all and give them disabled menu items!

    final experience:  i'm running a version of my project which
    was compiled with Think C 4 and TCL 1.0 (it'll be weeks
    before it runs smoothly with 5.0 and 1.1).  for the same
    reasons of disbelieving curiosity i choose a menu item which
    i disable via gBartender->DisableCmd().  need i say more?
    i was treated to an error which i had tried to make impossible
    by following both apple's and Think's guidelines.

    WHAT IS GOING ON HERE?????

    i wish i were less angry about this.

    :jeff bellsey
    [e-mail]













Path: ucivax!gateway
From: [e-mail] (Daniel Edward Rudman)
Subject: Re: disabled menu items, and the meaning of life
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 77
Date: 4 Sep 91 23:46:16 GMT

    From [e-mail] Wed Sep  4 16:45:14 1991
    Received: from caen.engin.umich.edu by mondo.engin.umich.edu (NeXT-1.0 (From Sendmail 5.52)/mondo-1.0)
        id AA02587; Wed, 4 Sep 91 16:45:09 GMT-0500
    Received: from ics.uci.edu by caen.engin.umich.edu (5.64/1.35)
        id 53c895e75.001024b; Wed, 4 Sep 91 16:39:19 -0400
    Received: by ics.uci.edu id aa05065; 4 Sep 91 9:24 PDT
    Received: from ics.uci.edu by ics.uci.edu id aa04180; 4 Sep 91 9:23 PDT
    Received: from USENET by ics.uci.edu id aa04124; 4 Sep 91 9:20 PDT
    From: [e-mail]
    Subject: disabled menu items, and the meaning of life
    Message-Id: <[e-mail]>
    Newsgroups: fa.think-c
    Date: 4 Sep 91 16:20:04 GMT
    To: [e-mail]
    Status: RO


    hi all,


    i've had quite the lesson this week.  as you read this,
    see if you have a reasonable answer to the question
    "what are disabled menu items for?".

    first experience:  for whatever reason, i chose the
    disabled "Open Selection" menu item in Think C 5.
    no selection was chosen, just a friendly blinking
    cursor.  so Think churns for a moment and tells me
    that "file "" not found".  this only works when using
    the mouse to select the menu item, not command-D.  (it
    also works in Think C 4.)  why does Think allow you to
    choose a disabled menu item?

    next experience:  now i'm curious.  while in the finder
    (7.0), all windows closed and no items on the desktop
    selected, the "view" menu and all of its items are dimmed.
    i have left a few straggling icons on the desktop, but
    no windows.  so, with the mouse i choose "by name" from
    the disabled menu.  all i can say is, well, try it and
    tell me it ain't a bug.  not only is the disabled menu item
    usable, but it does wrong things to the screen.  all of the
    "view" menu items work similarly.

    by this time i've come to question all that i hold sacred.
    what really are disabled menu items for?  at the state of
    my current project, i have so many bugs that i just might
    take them all and give them disabled menu items!

    final experience:  i'm running a version of my project which
    was compiled with Think C 4 and TCL 1.0 (it'll be weeks
    before it runs smoothly with 5.0 and 1.1).  for the same
    reasons of disbelieving curiosity i choose a menu item which
    i disable via gBartender->DisableCmd().  need i say more?
    i was treated to an error which i had tried to make impossible
    by following both apple's and Think's guidelines.

    WHAT IS GOING ON HERE?????

    i wish i were less angry about this.

    :jeff bellsey
    [e-mail]




---------------
The problem closely resembles a reported bug with Apple's unreleased utility,
Magic Apple. Magic Apple, which is now outdated by Now Utilities 3.0's
NowMenus and also by SuperMenu, used to allow you to place folders in the
Apple Menu and work through the folders as pop-ups.

Apple's big bug allowed you to select disabled menus.

Remove the utility immediately and all will be better.

//Dan










Path: ucivax!gateway
From: [e-mail]
Subject: Re: disabled menu items, and the meaning of life
Message-ID: <[e-mail]>
In-Reply-To: Your message of 04 Sep 91 16:20:04 GMT.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 5 Sep 91 00:28:11 GMT



...OK....  Do you have an extension called Magic Apple (by Fred Hollander,
HandOff Corporation)?  If so, turn it off and restart.  You probably won't
be able to select disabled menu items any more.  (If you can, then please
let me know.  I'm under the impression that this phenomena is caused by
Magic Apple, and Magic Apple alone.)

Personally, I can't live without Magic Apple, so until there's a new version
of it, I'm just going to have to be careful about where I let the mouse
button up.


Mike.
_____________________________________________________________________________
Michael A. Kelly                                         Apple Computer, Inc.
[e-mail]                 Advanced Technology Group, Graphics Software
_____________________________________________________________________________










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Floating Windows vs Windows
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 38
Date: 5 Sep 91 10:11:29 GMT

>What is the difference between floating windows and
>normal windows?

The difference is that floating windows, er, float. A floating window
generally provides a pallette of tools or options which you want visual
access to continually. Hence, a floating window is always on top of other
windows. There is still a notional top-window of the ordinary kind, and
this still accepts mouse clicks and key events as if the floating window
weren't there (assuming the floater is out of the way).

>When they must be used?

I presume you're asking about user interfaces. I've explained what I think
is the main rationale. (I also use "sinking" windows which are always at
the
bottom and always active, for a different kind of interface.) One point:
floating windows should vanish when the application goes into the
background.

>Is there a
>speed/memory factor that will make choose one over another.

I very much doubt it. If there *were* a speed/memory difference, that's not
sufficient reason to choose. It's an interface issue, not a performance
one.

>If you know C well and have never programmed on the Mac
>would you recommend using TCL or write code directly in C.

I recommend reading through Inside Mac I and II for background on the
Toolbox managers and routines, and the general way the machine works
(graphics environments, resource and memory management, and so on). Having
done that, I see no reason why you shouldn't just start with the TCL. I
started with C and TransSkel, which was interesting but didn't teach me
anything specifically important for TCL programming.

        Nick.











Path: ucivax!gateway
From: [e-mail]
Subject: can of worms too big, please retreat...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 6 Sep 91 02:50:43 GMT


sorry all,

for those that haven't got word (hard to tell which responses
came to me only or to the whole list),  the disabled menu item
problem was indeed causes by that little devil "magic apple."
(perhaps a magic apple with a chaotic good alignment ;)  i
sheepishly retire into my corner, humbled and tired, requesting
pardon in my continuing pursuit of the Truth of the User
Interface.

and may all init's perish a horrible death!  (except the good
ones).

:jeff bellsey

[e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: MacApp 2.xx with Think Pascal 3.02
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 6 Sep 91 20:27:09 GMT

I have converted MacApp 2.0b to think pascal 3.02 using the supplied
script.
Is there a newer version of this script ? and if so, where can I get it
from?
Thanks in advance.

Carlos Bazzarella.
University of Waterloo.
[e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 7 Sep 91 01:34:42 GMT

I got my update to 5.0. I tried to run the new TCL demo
in the NewClassDemo folder. However it was unable to compile.
First I got a prototype error on CDialog.c in SetWRefcon
on the second argument.

I changed that and kept going thinking that that on ewas a minor
error. By the way I just put a long instead of the variable this.
Iam not sure that this is correct but at least it kept compiling.

The major compiling error happened in CIconPane.c. Here all the
definitions of objects and methods are different than in the
CIconPane.h file. There are so many differences that I decided to
write this message and see if someone else has solved this problems.

If somebody from Symantec is out there, can you explain what's wrong w
with these new classes. Can you provide fixes so they can compile.

Thanks for your help.











Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 7 Sep 91 02:34:29 GMT

Please disregard my message about compiling errors in
the NewClassDemo folder. I had AppMaker on the same path
as Think C and there are routines for the Dialog Class which
have the same name. I was compiling the AppMaker routines instead
of the TCL.

Sorry about that.











Path: ucivax!gateway
From: [e-mail] (Kerry 'UPE' Cianos)
Subject: Magic Apple
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 11
Date: 8 Sep 91 23:38:33 GMT
X-Envelope-to: [e-mail]


  I've heard about this neato hack Magic Apple.  Is this available
somewhere??  FTP??  It sounds like a utility a could really use!  Thanks,

      Kerry

  ------------------------------------------------------------------------
  Kerry Cianos, President                PS/2 = PS divided by 2 =
  Impress Technologies                   half a computer, thats ok, OS/2
  Email : [e-mail]           is only half an operating system!











Path: ucivax!gateway
From: [e-mail]
Subject: unsubscribe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 9 Sep 91 13:33:21 GMT

Please take me off the think c mailing list.

Thanks

Ed











Path: ucivax!gateway
From: [e-mail] (Chuq Von Rospach -- Only here for the beer)
Subject: Re:  Magic Apple
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 9 Sep 91 15:46:21 GMT


>  I've heard about this neato hack Magic Apple.  Is this available
>somewhere??  FTP??  It sounds like a utility a could really use!  Thanks,

It was an improperly released (and buggy) beta test version of a tool that's
part of the commercial package HandOff II. If you want a copy, buy the
package. If you have a copy, it's illegal.











Path: ucivax!gateway
From: [e-mail] (Mark Alldritt)
Subject: TCL Bug (?) in CObject::Copy
Message-ID: <9109091397*[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 9 Sep 91 16:45:26 GMT

I have run into a problem with CObject::Copy.  This method is supposed to
create a copy of its object instance and return a handle to the new copy
to the caller.  When I use this method the handle returned does not point
to an object.  In the debugger, the __cn() macro returns a blank string even
though a valid handle (non-NULL) is returned, and when I try and use any
methods from the object a failure handler is triggered.  I have checked that
the object i'm copying is valid.

I think this problem exists in both TCL 1.0 and 1.1 as the consiquences of this
problem were evident in my application before I switched to TCL 1.1.

Does anyone have any ideas?

Thanks in advance
-Mark











Path: ucivax!gateway
From: [e-mail] (Mark Alldritt)
Subject: Menu font and size
Message-ID: <9109091398*[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 9 Sep 91 17:16:02 GMT

I've been looking though inside Mac I-VI for a way to alter the font and point
size for menus (specifically for popup menus) with no success.  Can someone
please point me in the right direction?

Thanks in advance

-Mark










Path: ucivax!gateway
From: [e-mail] (Raymond Degennaro)
Subject: NewClassDemo bugs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 9 Sep 91 19:07:07 GMT

this isn't really a THINK C problem, but it's related.  i have THINK Pascal
and i tried to run the NewClassDemo, and i recieved a compilation error on
what appeared to be a perfectely good line and i could not get it to run at
all.  However, if i built an application, everything worked fine. weird, eh?











Path: ucivax!gateway
From: [e-mail] ("Pettinati, Fabio")
Subject: unsubscribe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 9 Sep 91 21:20:52 GMT

Please remove my name from think-c mailing list.











Path: ucivax!gateway
From: [e-mail] (Kerry 'UPE' Cianos)
Subject: MAgic and Scribble
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 11
Date: 9 Sep 91 21:29:43 GMT
X-Envelope-to: [e-mail]


  Thanks for the info on Magic Apple - I'm gonna look into Now Utilities
and Hand-Off II.  Thanks!

          - kerry

  ------------------------------------------------------------------------
  Kerry Cianos, President                PS/2 = PS divided by 2 =
  Impress Technologies                   half a computer, thats ok, OS/2
  Email : [e-mail]           is only half an operating system!











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Menu font and size
Message-ID: <[e-mail]>
In-Reply-To: Your message of 09 Sep 91 17:16:02 GMT.
             <9109091398*[e-mail]>
Newsgroups: fa.think-c
Lines: 44
Date: 9 Sep 91 21:58:37 GMT


>I've been looking though inside Mac I-VI for a way to alter the font and point
>size for menus (specifically for popup menus) with no success.  Can someone
>please point me in the right direction?

If you're using System 7, all you have to do is specify popupUseWFont in your
call to NewControl (as in IM-VI, page 3-18).  If you're not using the standard
popup CDEF, it's a little harder, since the problem becomes how to get
PopupMenuSelect to use the port's font and style.  Since PopupMenuSelect
always uses the system font, the only way I've found to change its behavior
is to change the system font before the call to PopupMenuSelect, and change
it back immediately after.  This goes something like this:

/* In Think C */

extern short SysFontFam : 0xBA6;
extern short SysFontSize : 0xBA8;

short oldSysFontFam, oldSysFontSize;

...

oldSysFontFam = SysFontFam;
oldSysFontSize = SysFontSize;

SysFontFam = /* Insert your favorite font number here */
SysFontSize = /* Insert your favorite font size here */

PopupMenuSelect( ... )

SysFontFam = oldSysFontFam;
SysFontSize = oldSysFontSize;



This seems to work okay.  But then, I haven't tested it extensively.
(Your mileage may vary.)


Mike.
_____________________________________________________________________________
Michael A. Kelly                                         Apple Computer, Inc.
[e-mail]                 Advanced Technology Group, Graphics Software
_____________________________________________________________________________










Path: ucivax!gateway
From: [e-mail] (Vince Cavasin)
Subject: (none) (fwd)
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Motto: "I have come here to chew bubble gum and kick ass, and I'm all out
        of bubble gum."  --Roddy Piper, in _They Live_
Lines: 33
Date: 9 Sep 91 22:53:08 GMT


This got delivered to me due to some sort of mail hemhorrage:

Forwarded message:
> From [e-mail] Fri Sep  6 21:05:30 1991
> From: [e-mail]
> Subject: (none)
> Message-Id: <[e-mail]>
> Newsgroups: fa.think-c
> Date: 7 Sep 91 01:34:42 GMT
> To: [e-mail]
>
> I got my update to 5.0. I tried to run the new TCL demo
> in the NewClassDemo folder. However it was unable to compile.
> First I got a prototype error on CDialog.c in SetWRefcon
> on the second argument.
>
> I changed that and kept going thinking that that on ewas a minor
> error. By the way I just put a long instead of the variable this.
> Iam not sure that this is correct but at least it kept compiling.
>
> The major compiling error happened in CIconPane.c. Here all the
> definitions of objects and methods are different than in the
> CIconPane.h file. There are so many differences that I decided to
> write this message and see if someone else has solved this problems.
>
> If somebody from Symantec is out there, can you explain what's wrong w
> with these new classes. Can you provide fixes so they can compile.
>
> Thanks for your help.
>
>











Path: ucivax!gateway
From: [e-mail] (Vince Cavasin)
Subject: (none) (fwd)
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Motto: "I have come here to chew bubble gum and kick ass, and I'm all out
        of bubble gum."  --Roddy Piper, in _They Live_
Lines: 21
Date: 9 Sep 91 23:03:03 GMT

this too:

Forwarded message:
> From [e-mail] Fri Sep  6 23:19:01 1991
> From: [e-mail]
> Subject: (none)
> Message-Id: <[e-mail]>
> Newsgroups: fa.think-c
> Date: 7 Sep 91 02:34:29 GMT
> To: [e-mail]
>
> Please disregard my message about compiling errors in
> the NewClassDemo folder. I had AppMaker on the same path
> as Think C and there are routines for the Dialog Class which
> have the same name. I was compiling the AppMaker routines instead
> of the TCL.
>
> Sorry about that.
>
>











Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: Menu font and size
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 39
Date: 10 Sep 91 00:33:21 GMT

>I've been looking though inside Mac I-VI for a way to alter the font and point
>size for menus (specifically for popup menus) with no success.  Can someone
>please point me in the right direction?

Here is some code I use (doctored to be more general):

extern short SysFontFam : 0xBA6;
extern short SysFontSize : 0xBA8;
extern long LastSpExtra : 0xB4C;
extern long CurFMInput : 0x988;

long PopUpMenuDialogFont(MenuHandle theMenu, Point thePoint,
                         short theSelection, DialogPtr theDialog)
{
        long menuReturn;

        SysFontFam = theDialog->txFont;
        if(SysFontFam == applFont)
                SysFontFam = ApFontID;
        SysFontSize = theDialog->txSize;
        CurFMInput = -1L;
        LastSpExtra = -1L;
        menuReturn = PopUpMenuSelect(theMenu, thePoint.v, thePoint.h,
                                     theSelection);
        SysFontFam = systemFont;
        SysFontSize = 0;
        CurFMInput = -1L;
        LastSpExtra = -1L;
        return menuReturn;
}

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet/ARPAnet/EDUnet  : [e-mail]
BITNET (if no other way) : FREE0285@UIUCVMD











Path: ucivax!gateway
From: [e-mail]
Subject: What bugs are there (really) in Think C 5?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 10 Sep 91 00:55:58 GMT



OK, I'm about to start converting an important project from Think C 4.0.5
to Think C 5.0.  I've noticed several bug reports on c.s.m.p., but I'm not
sure which ones were really bugs and which were just programmer error.

Are there any actual bugs in Think C or the class library?  Are there any
particularly nasty new features I should watch out for?

Thanks,

Mike.
_____________________________________________________________________________
Michael A. Kelly                                         Apple Computer, Inc.
[e-mail]                 Advanced Technology Group, Graphics Software
_____________________________________________________________________________










Path: ucivax!gateway
From: [e-mail] (james frederick amundson)
Subject: Bug and question
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 10 Sep 91 03:46:24 GMT

I've seen many reports of bugs in Think C 5.0 lately.  It seems that most of
them are really misunderstandings about the features of a C standard created
by a committee.  I'm pretty confident my bug is legit, however.  When
optimization is on all of the local floating point variables in my subroutine
are assigned to the same location, be it an address or a register.  I
certainly hope this isn't a feature of ANSI C. 8-)

Is the above bug already documented?  If not, I will try to isolate the
specifics.  (Is anyone from Symantec listening?)

My question arises from trying to trace down this bug. If I declare
    double x;
and I want to see where it was assigned, I type
    &x
in the debugger.  This gives me an address UNLESS x is assigned to a register.
How do I figure out which register x is assigned to in the latter case? Thanks
to anyone who can help.

--Jim Amundson
  [e-mail]










Path: ucivax!jhummel
From: [e-mail] (Joseph Edward Hummel)
Subject: Re: Bug and question
Nntp-Posting-Host: wave.ics.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail] (Joseph Edward Hummel)
Organization: UC Irvine Department of ICS
Lines: 24
Date: 10 Sep 91 04:51:50 GMT
References: <[e-mail]>

In article <[e-mail]> [e-mail] (james frederick amundson) writes:
>I've seen many reports of bugs in Think C 5.0 lately.  It seems that most of
>them are really misunderstandings about the features of a C standard created
>by a committee.  I'm pretty confident my bug is legit, however.  When
>optimization is on all of the local floating point variables in my subroutine
>are assigned to the same location, be it an address or a register.  I
>certainly hope this isn't a feature of ANSI C. 8-)
>
>Is the above bug already documented?  If not, I will try to isolate the
>specifics.  (Is anyone from Symantec listening?)

I'd have to see the code, but this is perfectly legal for the compiler to
do IF at most one such variable is "live" (contains a value that will be
read in the future) at any given time.  The compiler is reusing the storage
for each different variable, since in this case only one variable is really
needed.

Can you post the source?

  - joe
--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: What bugs are there (really) in Think C 5?
Message-ID: <[e-mail]>
Posted-Date: Tue, 10 Sep 1991 09:42:11 -0600
Newsgroups: fa.think-c
Lines: 36
Date: 10 Sep 91 14:54:59 GMT


The one bug I've run into is with the UnloadA4Seg call.  I was using it in
a large multi-segment cdev.  Basically, calling UnloadA4Seg tends to crash
the machine, particularly if heap scrambling is enabled at the time.
Sometimes the crash occurs the first time UnloadA4Seg is called, sometimes
only after it's been called a dozen times.  I haven't seen any evidence
that this problem is with my code -- the exact same code compiled with
4.0.x works great, and a lot of people use it routinely.

I sent off a more detailed description of this problem (which I didn't
think to keep a copy of) to Phil Shapiro at Symantec several weeks ago, but
haven't heard anything in reply.  Did the report ever reach you, Phil?

One other problem I ran into was a crash that consistently occurred
whenever I'd click on a class in the class browser to try to get at the
pop-up menu of methods.  I was using 32 bit addressing and virtual memory
at the time, but I believe that I narrowed the problem down to the 32 bit
addressing (I really wish I'd kept a copy of that problem report I sent).
Oddly enough, removing all INITs, cdevs and RDEVs from my System 7 setup
didn't help, but booting with the shift key held down *did* fix the
problem.  So, this problem may not be in THINK C 5, but in, perhaps,
something like the EtherNet driver in the System file, which would have
been disabled by the shift key trick, but not by the removal of all INITs,
cdevs and RDEVs.  It's pretty weird interaction, in any case.

If anyone can shed any light on these problems (particularly the
UnloadA4Seg matter), I'd appreciate it.

----Chris (Johnson)
[e-mail]

P.S.  Apart from these problems, I've been extremely pleased with 5.0.














Path: ucivax!gateway
From: [e-mail] (james frederick amundson)
Subject: Re: Bug and question
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 10 Sep 91 16:42:11 GMT

Everyone,

Good grief.  My mistake.  The compiler was assigning variables in a legal
way.  I had a seperate bug that was clouding my judgement.  My apologies.

Thanks to those who responded.

--Jim Amundson










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re: What bugs are there (really) in Think C 5?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 10 Sep 91 18:22:49 GMT

Both of the things you report have been fixed internally, and will be included
in an upcoming patch.

R.










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] (John Draper)
Subject: I volunteer to make up think c 5.0 bug list.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 12 Sep 91 09:56:18 GMT

Now that Think C 5.0 is officially released,  and  people are already
finding bugs in it,   I think that it would be a good idea for someone
(I volunteer) to compile up a list of the current known bugs and problems
into a single file,  then post it to the mailing list for those people
who have not yet worked with it.

I propose that I post this bug list every month or so,   and I am in
the process of collecting them now,  based on the reports that people
have posted so far.   Naturally,  I cannot verify the authenticity of
the bugs,  but perhaps Phil Shipero can help out with this in some way.

My question to the group is...  Has anyone already done this??   if so,
then would it be possible to share this information and work with me
in generating this list??

I think this will help the group as a whole and especially those who
are just now getting the upgrade and plan on using it.

John Draper










Path: ucivax!gateway
From: [e-mail]
Subject: Returned mail: User unknown
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 50
Date: 12 Sep 91 12:39:44 GMT

>Subject: Think C v5 problems
>
>Dear Symantec:
>My students and I have used Think C for years, but the recent upgrade to
>v.5 (along with System 7.0) has got me stumped (I'm a registered user,
>serial number 05000-19500-17339-82268).  The following compiler errors
>occur in code that worked fine prior to version 5.0:
>
>    Argument to functions 'BeginUpdate' and 'EndUpDate' does not match
>prototype:
>
>    case updateEvt:
>                BeginUpdate( gTheEvent.message );
>                UpDateWindow( gMainWindow );
>                EndUpdate( gTheEvent.message );
>                break;
>
>    Last argument to function 'GetNewDialog' does not match prototype:
>
>    mSimulationDialog = GetNewDialog( SIMULATION_DLOG, NIL_POINTER,
>MOVE_TO_FRONT );
>
>and also in GetNewWindow, where MOVE_TO_FRONT is just -1L
>
>    Invalid redeclaration of SetColor:
>
>    SetColor( float intensRatio)
>{
>    if (intensRatio > 0.50 )         ForeColor( redColor );
>    else if (intensRatio > 0.25)    ForeColor( magentaColor );
>    else if (intensRatio > 0.125)    ForeColor( yellowColor );
>    else if (intensRatio > 0.0625)    ForeColor( greenColor );
>    else if (intensRatio > 0.03125)    ForeColor( cyanColor );
>    else                             ForeColor( blueColor );
>}
>
>    syntax error:
>
>GetDoubleIn( DialogPtr theDialog, int itemNumber, double *theDouble,
>Boolean *error );
>
>Please suggest what may be wrong here.  Have the prototypes or syntax
>changed?
>
>Erich Carr Everbach
>[phone]
>
>
>











Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Think C v5 problems
Message-ID: <[e-mail]>
In-Reply-To: Your message of "12 Sep 91 12:39:44 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 58
X-Mts: smtp
Date: 12 Sep 91 18:49:33 GMT

> Dear Symantec:
> My students and I have used Think C for years, but the recent upgrade to
> v.5 (along with System 7.0) has got me stumped...

I'm not from Symantec, but perhaps I can help...

> The following compiler errors
> occur in code that worked fine prior to version 5.0:
>
>     Argument to functions 'BeginUpdate' and 'EndUpDate' does not match
> prototype:
>
>                 BeginUpdate( gTheEvent.message );
>                 UpDateWindow( gMainWindow );
>                 EndUpdate( gTheEvent.message );

THINK C 5.0 is much stricter about checking arguments to Toolbox
routines than it used to be.  Previously, only the size of the
argument mattered; now, the type must match as well.  In this case,
BeginUpdate and EndUpdate need to have pointers (to a window) as
arguments, so you must cast the event record's "message" field, which
is a long, to a pointer type:

    BeginUpdate ((WindowPtr) gTheEvent.message);
    ...
    EndUpdate ((WindowPtr) gTheEvent.message);

>     Last argument to function 'GetNewDialog' does not match prototype:

This is the same problem.  Try redefining MOVE_TO_FRONT as
"((WindowPtr) -1".  Note that these issues *are* discussed in the
THINK C 5.0 manual; check Appendix A, which discusses upgrading to 5.0
from 4.0 (I think; I don't have the manual in front of me).

>     Invalid redeclaration of SetColor:

SetColor is a Color QuickDraw routine, which is now defined as an
inline function in QuickDraw.h (which in turn is included in
MacHeaders).  As you can't redefine functions which have previously
been defined as inline, you'll probably have to rename this function.

>     syntax error:
>
> GetDoubleIn( DialogPtr theDialog, int itemNumber, double *theDouble,
> Boolean *error );

As mentioned in the manual, THINK C 5.0 follows the stricter ANSI
rules about declaring prototypes; you must specify a return value in a
prototype.  Here you'll want either "int" (which is what 4.0 assumed
you meant) or "void" (which is probably what you really meant).

Hope this helps.  (And do read through the new manuals -- they're
greatly improved, apart from a distressingly large number of typos.)

-- Russell S. Finn
[e-mail]












Path: ucivax!gateway
From: [e-mail]
Subject: Name of CurResFile
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 16 Sep 91 14:39:41 GMT

In some application (Cabri-geometre indeed) I need to know the name of the
current opened resource file.
It exists a function CurResFile returning the path reference number of the
current opened resource file but I do not see any way from going from there
to the name of that file.
(High level or lowlevel file routines do not help and I did not find
anything more using the newer SFSpec stuff.
Does somebody has an idea?

By the way who knows where it would be possible to have a description of
the way of implementing AppleEvents using Hypercard (>=2.1)?

Thank you for help
 Jean-Marie Laborde   [e-mail]    BP 53x 38041 Grenoble cedex FRANCE
 (33) 76 51 46 10   (sec 76 51 46 16)   (Fax [phone])











Path: ucivax!gateway
From: [e-mail] (Taylor Leaming 801/582-5847 x3836)
Subject: Not recieving mail list at my end...broken?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 25
Date: 16 Sep 91 17:49:19 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

Hi,

I don't mean to burn up bandwidth with this message, but I haven't recieved a
single message from this mail list in over a week.  I'm trying to determine
if my mail system is bouncing messages or something.

Would several of you mind sending a new message to me (off-line) at:

        [e-mail]

If you don't get a reply within a reasonable amount of time, would you mind
then giving me a call at 801/582-5847.  I'd like to talk to you and see if
I can get things straightened out.  This is asking a lot, but it would be
very helpful and much appreciated.

Thanks in advance,

Taylor

--------------------------------------------------------------------------
Taylor Leaming                                  [e-mail]
Simulation Division
Evans & Sutherland Computer Corp.
SLC, UT                                                       801/582-5847











Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: Name of CurResFile
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 16 Sep 91 18:24:37 GMT

>In some application (Cabri-geometre indeed) I need to know the name of the
>current opened resource file.

Try this:

OSErr GetResFileName(short refNum, Str255 fileName)
{
        FCBPBRec myFCPPB;
        OSErr errCode;

        myFCBPB.ioVRefNum = 0;
        myFCBPB.ioRefNum = refNum;
        myFCBPB.ioFCBIndx = 0L;
        errCode = PBGetFCBInfo(&myFCBPB, false);
        if(errCode == noErr)
                BlockMove(myFCBPB.ioFCBFlNm, fileName, sizeof(Str255));
        return errCode;
}

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet/ARPAnet/EDUnet  : [e-mail]
BITNET (if no other way) : FREE0285@UIUCVMD











Path: ucivax!gateway
From: [e-mail] (Per Mildner)
Subject: Name of CurResFile
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 16 Sep 91 14:39:41 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 33
Date: 16 Sep 91 20:50:57 GMT


Getting The name of the current open resource file:
This is from working Think C 4.05 code. ioNamePtr should point to a
Str255 allocated by the caller. The name and the ioVRefNum is returned.

OSErr
application_file_spec(Str255* ioNamePtr, short* ioVRefNumPtr)
{    FCBPBRec pb = {0 };
    pb.ioCompletion = 0;
    pb.ioVRefNum = 0;
    pb.ioRefNum = CurResFile();    /* will be the current
                                           application if no other
                                           resource open */
    pb.ioFCBIndx = 0;
    pb.ioNamePtr = (StringPtr)ioNamePtr;
    if (noErr != (lastErr = PBGetFCBInfo(&pb, false /* !async */)))
        return lastErr;
    *ioVRefNumPtr = pb.ioVRefNum;
    return noErr;
}

AppleEvents and HyperCard 2.1:

There is a Release note for HyperCard 2.1, it describes
simple uses of the built in AppleEvents suppport. (e.g. sending
scripts to other HC applications) More advanced use requires
XCMDS which also is available from various sources.

Hope this helps. (I can send the HC 2.1 release notes if you haven't
already seen it.

Regards,
Per Mildner [e-mail]










Path: ucivax!gateway
From: eplunix![e-mail] (MarkNilsn)
Subject: DragHook
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 91
Date: 17 Sep 91 06:58:45 GMT

Hi folks,

I need some help sorting something out.  I am using the DragHook global
variable to store a function to be called when the user modifies the
size or position of a window.  IM volI says if I store a pointer to a
function in the global variable DragHook it will be called repeatedly
while the user drags the window.  It goes on to say that the function
will be called with no parameters.  Fine.  I can work with that.

So here is what happens.  I get into my event loop.  Do a mouseDown in
the drag bar and jump into the debugger ( I have it set up to do that ).
When I start to step through my code, I get an illegal instruction.

For those of you who have done this or think you can help me out, please
bear with the following code I have anotated with the problems.

By the way I am running think C 4.0.


This is the function I want called.

DragHookGetEventTimerEvents()
/* this proc gets stored in the DragHook ptr */
{
    GetEventTimerEvents();
}


This is what installs it.


SetUpDragHook()
{
    DragHook = DragHookGetEventTimerEvents;
}


This is on the recieving end of DragHookGetEventTimerEvents().
On a normal call HistogInfoPtr would have something valid in it.  It
works just fine normaly.  When it is called from DragHook HistogInfoPtr
is NULL and gets trapped by the if satement.

Basicly what I try to do is get the front window.  Exract the refcon
that has the valid data and run with it.  Everything works fine
until I call ETUpdateBuff.  I either hang or get an illegal instruction
message from the debugger.


GetEventTimerEvents(HistogInfoPtr)
struct    HistogInfo    *HistogInfoPtr;
{
    /* updated the Main Buffer and then the private Buffers from the */
    /* event Timer.  You can past any HistoInfoPtr in the list */
    /* vars for data and stuff */

    int numgotten;
    WindowPtr    TempW;

    if(HistogInfoPtr == NULL) /* ie it was called with DragHook */
        {
        TempW = FrontWindow(); /* I need to find the window */
        HistogInfoPtr = (struct HistogInfo *)GetWRefCon(TempW);
        Debugger();
        }
    /*fill buff and write to fp*/
    numgotten =
ETUpdatebuff(*(HistogInfoPtr)->FileHandle,HistogInfoPtr->MainBuffer);

    /* now cycle through all hystograms an update private bin counts */
    UpDatePrivateBuffers(HistogInfoPtr,numgotten);
}

Thanks for reading this far.  Everything has been working fine with
these functions.  I am sure ther is no obvious inherent bug  ;).

I have tried several other solutions with static and global variables
and that even looks stanger.  When I type the name of the variable into
the debugger it finds it but the value is 0.  This was true for statics
as well as Globals.

Well, thats it.  I hope I'm not wasting bandwidth by overlooking
something obvious.  Any hints will be appreciated.

--Mark.

PS. I just read over the letter and remembered that all the DragHook
stuff was in the "Assembly Language Note" parts of IM.  Do I need some
glue?  I've done a bit of 68000 asm but I should be able to do this in
C, right?

Thanks again.










Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: Name of CurResFile
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 25
Date: 17 Sep 91 14:08:31 GMT

My sincerest apologies for my posting of a piece of garbage code yesterday.
It was completely in error and will certainly not do what I said it would.
This is the correct version.

Again, I am very sorry, and embarassed. Thanks to Edward Huff for pointing
this out.

OSErr GetResFileName(short refNum, Str255 fileName)
{
        FCBPBRec myFCBPB;
        OSErr errCode;

        myFCBPB.ioNamePtr = fileName;
        myFCBPB.ioVRefNum = 0;
        myFCBPB.ioRefNum = refNum;
        myFCBPB.ioFCBIndx = 0L;
        return(PBGetFCBInfo(&myFCBPB, false));
}
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet/ARPAnet/EDUnet  : [e-mail]
BITNET (if no other way) : FREE0285@UIUCVMD











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Not recieving mail list at my end...broken?
Message-ID: <[e-mail]>
In-reply-to: Your message of "Mon, 16 Sep 91 13:49:19 EDT."
             <[e-mail]>
Newsgroups: fa.think-c
Orig-To: Taylor Leaming 801/582-5847 x3836 <[e-mail]>
Lines: 18
Date: 17 Sep 91 15:27:57 GMT


> Hi,
>
> I don't mean to burn up bandwidth with this message, but I haven't recieved a
> single message from this mail list in over a week.  I'm trying to determine
> if my mail system is bouncing messages or something.

Your address is a little odd in your mail header; I wonder if that is
causing problems with auto-reply?

I've been getting the mailing list, although it's been light.

Regards,
Dak
--
David A. 'Dak' Keldsen of SoftQuad, Inc. email: [e-mail]  phone: [phone]
"Just roll the dice and accept this as a tragic turn of events, OK?"
    -- Calvin and Hobbes










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Text highlighting
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 18 Sep 91 20:07:45 GMT

A  quick query about the compiler (4.0.5, since Europe won't be getting 5.0
for ages yet):

I have a Radius greyscale display. The week before last, TC's editor was
highlighting text in grey, which was rather nice. It's stopped doing it now
- it just inverts. Anybody got any idea why this might have changed? All I
can think of is some change to the display CLUT or something, but most of
the rest of the system (the Standard File dialog and so on) still
highlights text in grey. I'd quite like it back...

        Nick.











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Text highlighting
Message-ID: <[e-mail]>
In-Reply-To: Nick Rothwell's message of 18 Sep 91 20:07:45 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 19 Sep 91 02:06:17 GMT

From: Nick Rothwell <[e-mail]>

   A quick query about the compiler (4.0.5, since Europe won't be
   getting 5.0 for ages yet):

   I have a Radius greyscale display. The week before last, TC's
   editor was highlighting text in grey, which was rather nice. It's
   stopped doing it now - it just inverts. Anybody got any idea why
   this might have changed? All I can think of is some change to the
   display CLUT or something, but most of the rest of the system (the
   Standard File dialog and so on) still highlights text in grey. I'd
   quite like it back...

THINK C 4.0.x will never use the hilite "color", you must have had
some INIT installed that provided this service (by patching
_InvertRect).  Two INITs that do this are 4Plus and one called ThC
Hilite! by Alex Chaffee.

4Plus 1.4 is ftp'able from most places, and I can post ThC Hilite! if
anyone wants just the hilite feature -- I got it from CIS originally.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: What bugs are there (really) in Think C 5?
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 10 Sep 91 14:54:59 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 36
Date: 19 Sep 91 03:02:04 GMT

From: [e-mail]

   The one bug I've run into is with the UnloadA4Seg call.  I was
   using it in a large multi-segment cdev.  Basically, calling
   UnloadA4Seg tends to crash the machine, particularly if heap
   scrambling is enabled at the time.  Sometimes the crash occurs the
   first time UnloadA4Seg is called, sometimes only after it's been
   called a dozen times.  I haven't seen any evidence that this
   problem is with my code -- the exact same code compiled with 4.0.x
   works great, and a lot of people use it routinely.

There is a bug in the cache-clearing code that the code resource (and
DA) segment loader uses, that will cause a code resource to crash if a
segment is loaded after the main code resource is unlocked and moves.
I'll bet that this is the bug that you're running into.  We're working
on a patch to fix this, and it will be posted as soon as it's ready.

   One other problem I ran into was a crash that consistently occurred
   whenever I'd click on a class in the class browser to try to get at
   the pop-up menu of methods.

There's a 32 bit cleanliness bug in the Grep code that manifests if
THINK C gets loaded over the 16 meg watermark.  The browser uses a
grep string to search for method declarations, so that's where the
crash is coming from.

In any case, this is a known bug as well, and will be fixed in a
forthcoming patch.

I apologize for any inconvenience that these bugs have caused.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Adam Schabtach)
Subject: Re: Text highlighting
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Phil Shapiro" at Sep 19, 91 2:06 am
Newsgroups: fa.think-c
Lines: 10
Date: 19 Sep 91 03:31:26 GMT


> THINK C 4.0.x will never use the hilite "color", you must have had
> some INIT installed that provided this service (by patching

Out of curiosity, does TC v5.0 fix this? That was my main reason for
buying the upgrade (which I'm anxiously awaiting)... :-)

--Adam












Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Text highlighting
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 19 Sep 91 12:00:55 GMT

>THINK C 4.0.x will never use the hilite "color"

Ah. This explains why it wasn't working. I was running 4+ at the time, and
am running it now, but the highlight function seems to be broken right now.

I'll probably drop 4+ as I don't need all the mondo menu and command
features. All I want is command- and option-click to get menus of include
files and method names respectively. And colour highlight. I might just
wait and see what comes out of the box with TC5.0.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: UK release? (Re: What bugs are there (really) in Think C 5?)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 19 Sep 91 12:00:55 GMT

>In any case, this is a known bug as well, and will be fixed in a
>forthcoming patch.

Looks like here in the UK we'll be getting the patches before we even get a
sighting of TC5.0. Anybody else in the UK heard anything yet? I think I'll
nag Symantec UK again to see what's going in. TC5.0 is now out in Sweden, I
hear.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Text highlighting
Message-ID: <[e-mail]>
In-Reply-To: Adam Schabtach's message of 19 Sep 91 03:31:26 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 19 Sep 91 12:11:12 GMT

From: Adam Schabtach <[e-mail]>

   > THINK C 4.0.x will never use the hilite "color", you must have had
   > some INIT installed that provided this service (by patching

   Out of curiosity, does TC v5.0 fix this? That was my main reason for
   buying the upgrade (which I'm anxiously awaiting)... :-)

Yes, it's fixed.  However, the project window still uses black &
white.  I guess we're working on this one window type at a time :-).

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Craig Miller)
Subject: Wanted: Windows menu code (TCL)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 20 Sep 91 14:08:21 GMT

It seems to be that it would be fairly easy to
write code for a Windows menu that would be
fairly application independent.  CDesktop would
add and remove window titles from the Windows menu
when windows are added or removed from the desktop.
CApplication would ask CDesktop for a window
pointer and select that window in response to a
Windows menu selection.

Does anyone out there have code resembling the above?
I would appreciate a copy before I go out and re-invent
this particular wheel.  By the way, I am still using
TCL 4.0.5.

Craig D. Miller
Scientific Reasoning Research Institute (SRRI)
Hasbrouck Lab, University of Massachusetts, Amherst 01003
tel. [phone]   [e-mail]










Path: ucivax!gateway
From: [e-mail] (Chuq Von Rospach -- Only here for the beer)
Subject: INIT Icon placement
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 20 Sep 91 15:15:12 GMT


Can anyone point me to documentation on how INITs figure out how to place
themselves on the screen? (I realize there's a pre-written CODE resource to
do this, but I'm interested in how the INITs pass information from what to
another -- low memory locations?

I want to create a CDEV that allows me to re-locate the place where the first
INIT is placed. I'm guessing that this would simply mean getting in first and
'fixing' those memory locations, but I can't find any documentation on how
that stuff works. Any pointers would be appreciated.

(Why? Well, why not. I want to write a CDEV. Plus I have a two-monitor system
at home, with the menubar on my two-page, and this color monitor that I'd like
the icons to draw on during startup. Seems like a nice, useless hack).











Path: ucivax!gateway
From: [e-mail] ("Erik A. Johnson")
Subject: Re: INIT Icon placement
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 32
Date: 20 Sep 91 20:22:49 GMT

Chuq Von Rospach <[e-mail]> writes:
> Can anyone point me to documentation on how INITs figure out how to place
> themselves on the screen? (I realize there's a pre-written CODE resource to
> do this, but I'm interested in how the INITs pass information from what to
> another -- low memory locations?
>
> I want to create a CDEV that allows me to re-locate the place where the first
> INIT is placed. I'm guessing that this would simply mean getting in first and
> 'fixing' those memory locations, but I can't find any documentation on how
> that stuff works. Any pointers would be appreciated.
>
> (Why? Well, why not. I want to write a CDEV. Plus I have a two-monitor system
> at home, with the menubar on my two-page, and this color monitor that I'd like
> the icons to draw on during startup. Seems like a nice, useless hack).

Sounds like a neat idea.  I'd suggest taking a look at the source code for
the rather infamous ShowINIT (or its more recent cousin, ShowINITFamily,
or some such).  If I remember correctly, the ShowINIT does use a 4 bytes in
low memory area to store two 2-byte, signed integers, one for horizontal and
one for vertical location for the next INIT's icon.  Each time ShowINIT is
used it plots the icon and then advances the location.

ShowINIT source used to be available on the various archives.  (If it
has disappeared, send me e-mail and I'll dig it up.)


Erik A. Johnson        \    Internet: [e-mail]     \       |
------------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] ("Brian M. Hamlin")
Subject: class-less debugging story
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 21 Sep 91 09:54:34 GMT

All -

  As a TCL user, I was debugging one fine California afternoon. A case
presented itself which seemed noteworthy, and a pain-in-the-arse at that-

  If class A uses instance var B, B uses instance var C, all objects, and
one sets a breakpoint in A, then using that miracle of a Debugger, tries
to look at the contents of obscure, special subClass of something class C,
one finds that unless source file of class A *explicitly* includes
header file C, the Debugger returns with a ".. unknown class 'C'" !?!

  Even though through nested includes header file C *is* included, the
Debugger cannot figure this out! Of course, headers of instance vars
are only included in source files now, since the much needed addition
of the "class N;" forward declaration construct used in headers. But still,
the is Bad.

  A really good example, and a lead in to another discussion, is the
TCL v1.1 case of using CDialogDirector, CDialog and subPanes. Execute
a command in the Director, and viola
  This is really a bummer, as we say here... Am I missing something?

  In the past, I have used the Debugger to resolve particularly gnarly
expressions during runtime, just to save derefs through half a dozen files
or so (since the compile/run/edit is fast. we can do this!!)

  Now I am handicapped in this ability. Any thoughts ??











Path: ucivax!gateway
From: [e-mail] (John Miller)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 21 Sep 91 18:51:18 GMT


Using the "factory settings," I find that project sizes after bringing
them up to date are considerably larger than documented (for the
sample demo) and much over twice as large as the same project (my own)
in TC 4.

Reactions?  Am I missing something?  Will a 3.3meg project that is far
from its eventual size be problematic?

Thanks,

John











Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: MIDI Object
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 15
Date: 22 Sep 91 20:50:45 GMT
X-Phone: [phone] x115


From: Adam Schabtach <[e-mail]>
Subject: CMIDI object for archives
Date: Tue, 17 Sep 91 22:05:23 MDT

Hello--

Attached to this message is a submission for the THINK C archives: a TCL
object for MIDI Manager operations. I have no connections with the author;
nor have I even tested the code. I'm passing it along in hopes that someone
will find it useful.

--Adam

[saved as: /mac/think-c/classes/cmidi.hqx; 20K]










Path: ucivax!gateway
From: [e-mail] (Joseph Edward Hummel)
Subject: Assembly language environment for the Mac?
Nntp-Posting-Host: wave.ics.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Organization: UC Irvine Department of ICS
Lines: 13
Date: 24 Sep 91 00:56:10 GMT
Distribution: fa

[ Sorry this isn't a Think C question, but I thought you C hackers out there
  might have some ideas on this... ]

Hello all.  Can anyone suggest an assembly language environment for the
Mac (in particular,  a Mac Plus)?   I'm not looking for anything fancy, just
something to run in a student lab.  MPW is not an option, since I think it
requires more than a 1 Meg Mac.  Thanks in advance.

  - joe hummel
--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Assembly language environment for the Mac?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 36
Date: 24 Sep 91 10:55:01 GMT

- Hello all.  Can anyone suggest an assembly language environment for the
- Mac (in particular,  a Mac Plus)?   I'm not looking for anything fancy,
just
- something to run in a student lab.  MPW is not an option, since I think
it
- requires more than a 1 Meg Mac.  Thanks in advance.

        A few weeks ago, I found at the local university bookstore what you
 might need.It's called MAS - Macintosh Assembly System Basepak, runs on
 everything from a Plus and upwards, and runs efficiently in 350k of memory
 from a floppy disk!
I admit that I haven't used it much, but it seems to be a fully functional
interactive system for assembly language programming, which is basically
designed for the teaching of 68000 assembly programming.

  The environment is a bit like symantec's products, and it even has a
debugger.They also show how to use merge their object code with think-c
code.

 The publisher is Ramsoft in California , whom I have no afilliation
 whatsoever with.
This product is a small manual and a disk, and its ISBN number is
0-669-16087-3. Your bookstore should be able to order it.

There is no price tag, and I can't remember excaclty what I paid, but
It was rather cheap.

--------------------------------------------------------------------------
Sigurdur Darri Skulason                                    [e-mail]

Software manager,
Hugsun inc.
Tech.Dev. Centre, Dunhagi 5, IS-107 Reykjavik, Iceland
Fax : [phone] Tel: [phone]












Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Re: Assembly language environment for the Mac?
Message-ID: <[e-mail]>
In-Reply-To: Your message of "24 Sep 91 00:56:10 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 24
Date: 24 Sep 91 13:05:49 GMT


   From: Joseph Edward Hummel <[e-mail]>
   Date: 24 Sep 91 00:56:10 GMT

   Hello all.  Can anyone suggest an assembly language environment for
   the Mac (in particular, a Mac Plus)?  I'm not looking for anything
   fancy, just something to run in a student lab.  MPW is not an option,
   since I think it requires more than a 1 Meg Mac.  Thanks in advance.

Well, Think C is a decent assembly language environment, though MPW's
assembler is better. Don't get the Consulair Development System (CDS),
it's old and decayed.

Think about economics of the situation, BTW. TC 5.0 will cost you (at
student discount) about $90/Mac. If your lab has all the software
licenses it should, you've probably spent several hundred dollars per
Mac on software. At current memory prices, an additional two megabytes
of memory for each Mac is about $60. So, it seems ridiculous to choose
your software according to what runs in one megabyte.

Ephraim Vishniac    [e-mail]   [e-mail]
 Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142
        One of the flaws in the anarchic bopper society was
        the ease with which such crazed rumors could spread.










Path: ucivax!gateway
From: [e-mail]
Subject: Mounting AppleShare Servers
Message-ID: <[e-mail]>
Posted-Date: Tue, 24 Sep 1991 09:20:31 -0600
Newsgroups: fa.think-c
Lines: 11
Date: 24 Sep 91 14:22:13 GMT

Can anyone provide me with, or tell me where to look for, source code for
mounting AppleShare file servers?  I've recently found several projects in
which such a feature would be valuable.  Ideally, it would require only the
server, volume, zone and user names along with a password for parameters.

Thanks in advance for any help!

----Chris (Johnson)
[e-mail]
----University of Texas at Austin Computation Center











Path: ucivax!gateway
From: [e-mail] ("Matthew T. Russotto")
Subject: Re:  Assembly language environment for the Mac?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 24 Sep 91 17:14:58 GMT

Well, if you already have think C, you can use its inline assmebler feature.
There is also an old assembler called 'MDS' out there-- it's by Consulair,
and isn't an integrated environment, but rather separate pieces.










Path: ucivax!gateway
From: [e-mail]
Subject: serial ports
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 24 Sep 91 17:28:24 GMT

Does anyone know what the magic code for 38400 baud is?










Path: ucivax!gateway
From: [e-mail]
Subject: Re: serial ports
Message-ID: <[e-mail]>
In-Reply-To: Your message of "24 Sep 91 17:28:24 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 24 Sep 91 20:03:33 GMT

> From:    [e-mail]
> To:      [e-mail]
>
>Does anyone know what the magic code for 38400 baud is?

Apple hasn't defined numbers for all possible baud rates.  If they
don't have a number for the rate you want to use, you need to change it
by making a PBControl call to the driver with the csCode of 13, and the
baud rate in the csParam field.  (See IM II-254)
  --dave koziol










Path: ucivax!gateway
From: [e-mail]
Subject: Re:  Assembly language environment for the Mac?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 24 Sep 91 20:34:48 GMT


There is a shareware Assembler call MacAssembly I think. Its from Dave
McWherter. Below is the address from his DA MacSink. I'm not sure that MA
is still supported. The last version was 7.something. I hear that it was/is
one of the best assemblers for the mac.


   Preferred Publishers, Inc.
   5100 Poplar Ave., Suite 617
   Memphis, TN 38137

Or you can place a VISA, MC or AMEX order at [phone].

For information or support, call [phone].
_____________________________________________________________________
Disclaimer: Everything is relative, it all depends on the point of view
            of the observer.
_____________________________________________________________________
   Matthew Xavier Mora                   |  The keeper of the UMPG
   SRI International                     |  [e-mail]
   [sent using Eudora 1.2 ]              |  [e-mail]
_____________________________________________________________________











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: WDEFs-as-objects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 25 Sep 91 18:24:00 GMT

I'm toying with the idea of implementing a package for custom windows, and
would quite like to do it in the way that Greg implemented the custom menus
in the TC demo program, i.e. with a WDEF class hooked into a stub code
resource. My main question is whether this is provided in TC5.0, either in
the class library or the demo programs. We don't have TC5.0 in the UK yet,
and I don't want to do the work only to find it provided when the upgrade
materialises.

If there isn't a demo of this form, I'll give it a spin myself. Greg's WDEF
for tear-offs is a start, although I'll need to implement resizing,
zoom-boxes and so on.

Quickie tech. question: am I responsible for putting A5 somewhere safe? It
seems as if WDEFs are called directly by the Window Manager, so if one
application uncovers a window of another, the second app's window frame is
drawn immediately. I suspect the second app's register context isn't in
place here. (I believe this is the lowest of the three kinds of MultiFinder
context switch, so things like the resource file chain won't be in place
either.)

        Nick.











Path: ucivax!gateway
From: [e-mail]
Subject: Re: WDEFs-as-objects
Message-ID: <[e-mail]>
In-Reply-To: Nick Rothwell's message of Wed 25-Sep-91  6:24pm.
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 21
Date: 26 Sep 91 02:46:24 GMT

In your message of Sep 25,  6:24pm, you write:
>
> I'm toying with the idea of implementing a package for custom windows, and
> would quite like to do it in the way that Greg implemented the custom menus
> in the TC demo program, i.e. with a WDEF class hooked into a stub code
> resource.

I tried this, but it didn't work.  I asked Greg Dow about it, and he
said something about a weird bug (I don't recall the specifics).

The bug might have been fixed in THINK C 5, if it was related to THINK C 4,
so its probably worth trying again :-).

-Eric


--
Eric K. Olson, Editor, Prepare()      NOTE:     [e-mail] doesn't work
Lexington Software Design             Internet: [e-mail]
72A Lowell St., Lexington, MA  02173  Uucp:     harvard!endor!olson
[phone]                        Bitnet:   OLSON@HARVARD










Path: ucivax!gateway
From: [e-mail] (Darke Childe)
Subject: Please remove me from this list.
Message-ID: <[e-mail]>
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
Newsgroups: fa.think-c
Lines: 3
Date: 26 Sep 91 03:47:45 GMT

thank you

--










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: WDEFs-as-objects
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 26 Sep 91 02:46:24 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 26 Sep 91 13:30:38 GMT

From: [e-mail]

   In your message of Sep 25,  6:24pm, you write:
   >
   > I'm toying with the idea of implementing a package for custom windows, and
   > would quite like to do it in the way that Greg implemented the custom menus
   > in the TC demo program, i.e. with a WDEF class hooked into a stub code
   > resource.

   I tried this, but it didn't work.  I asked Greg Dow about it, and he
   said something about a weird bug (I don't recall the specifics).

   The bug might have been fixed in THINK C 5, if it was related to THINK C 4,
   so its probably worth trying again :-).

Unless I'm mistaken, the problem doesn't have to do with the OOP
environment in THINK C, but with the fact that the Window Manager
isn't reentrant.  If that's the case, then you should have no more
difficulty in doing this than implementing a custom WDEF in any other
program when using the "embedded defproc" method.

The only restriction you'd have is that you wouldn't be able to
single-step through the code, and if you got a bus error in that code,
you'd crash the debugger.  The only way to fix this is to use a
debugger that doesn't use the Window Manager, like MacsBug or TMON.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: WDEFs-as-objects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 26 Sep 91 16:34:43 GMT

>I tried this, but it didn't work.  I asked Greg Dow about it, and he
>said something about a weird bug (I don't recall the specifics).

As in, a bug in TC4.0.x? Hmm. Apart from some A5 voodoo, I don't see why
it should be any harder than the MDEF example.

I suppose I'd better find somewhere to store A5. I was thinking of putting
in at the end of the two dimensions rectangles stored in dataHandle...

I'll let y'all know how I get on...

        Nick.











Path: ucivax!gateway
From: [e-mail]
Subject: GetKeys Source Code
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 26 Sep 91 16:40:18 GMT

I'm having trouble using the GetKeys function with THINK C.  Can anyone
offer any assistance?  I gave it a shot, but I guess I'm still doing
something wrong.

My understanding is that in pascal GetKeys returns a packed array of 128
Booleans (bits?).  If a bit is on then that key is pressed.  In THINK C,
GetKeys returns 128 bits in the form of an array of 4 longs, KeyMap[4].  My
trouble is extracting the bit information from the 4 longs.

Any help would be greatly appreciated.  Thanks.  :-)


-------------------------------------
- Richard Beecher ([e-mail]) -
--------------------------------------











Path: ucivax!gateway
From: [e-mail] (John Miller)
Subject: MIDI routines in TC5--Help! (Please!!)
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 5
Date: 27 Sep 91 00:25:42 GMT


Has anyone tried to use MidiPascal 3.0 with Think C 5.0 (TCL 1.1) and
gotten it to work?  After many hours of converting my project to TCL 1.1,
I finally got to the point where I could test some of my MIDI code only
to find that nothing worked anymore.  Suggestions, anyone?










Path: ucivax!gateway
From: [e-mail]
Subject: Stupid Novice Programmer Question
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 27 Sep 91 13:25:00 GMT

I'd like to open up a CDataFile when starting up my program
to read in some initial data.  I'd like to be able to specify
a path name but if it has to be in the System Folder (or better,
the Preferences Folder) that's fine.

I'm having trouble constructing the arguments to pass to the
SpecifyHFS method.  Would someone be kind enough to send me
some simple example code?

aTdHvAaNnKcSe,
Ian Dowell
[e-mail]










Path: ucivax!gateway
From: paulr@planet8. (Paul Raulerson)
Subject: Think-C and Oracle
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 27 Sep 91 13:42:52 GMT

Arrrrgh!! Has anyone else here tried to use Think-C with Oracle? It is not exactly
an easy task, and this time, the fault is certainly not Symantec's!

First, though it will compile quite reasonably under Think-C 5.0, under System-7,
any attempt at execution results in an un-implemented instruction trap. (Anyone
proficient at using MacsBug? Please drop me a line on how to pinpoint the beast! :)

Under System-6.07, after removing a ton of the MPW Include files, it compiles and
runs with an unimplemented instruction trap, but cannot connect with the Oracle
database... even though Hypercard has nooooooo problem doing so! Drat Drat Drat!

Oracle isn't much of any help, since I bought the database 2nd hand and they want
me to sign over my first born son saying it isn't illegal. (Sorta willing... that
Database ENgine is *nice*. :)

In any case, if anyone out there has tangled with this Oracle beast, and has Think-C
working well with it, *please* point out what manner of dragon you had to slay to
get there. ;)  Oh yeah- Oracle version is 1.2 (database version) for Macintosh.
Thanks!
-Paul










Path: ucivax!gateway
From: [e-mail] (Mark Alldritt)
Subject: THINK Reference
Message-ID: <9109271418*[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 27 Sep 91 16:43:24 GMT

Does anyone know if or when the THINK Reference will be upgraded to include
information from Inside Mac VI?

Thanks
-Mark










Path: ucivax!gateway
From: [e-mail] (Per Mildner)
Subject: SetPenState declaration bug?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 27 Sep 91 18:27:01 GMT

It's declared (Think C 5.0 Quickdraw.h)
pascal void SetPenState(const PenState *pnState) = ...
shouldn't that be
pascal void SetPenState(const PenState pnState) = ...

Per Mildner ([e-mail])










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: WDEFs-as-objects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 27 Sep 91 18:27:11 GMT

>The only restriction you'd have is that you wouldn't be able to
>single-step through the code, and if you got a bus error in that code,
>you'd crash the debugger.  The only way to fix this is to use a
>debugger that doesn't use the Window Manager, like MacsBug or TMON.

Or even (shriek!) not use a debugger at all...! Actually, I have some
secure diagnostic routines which I implemented for debugging at the MIDI
interrupt level, so I should be able to manage if I take care... The A5
saving I'll have to think about. Thanks for the debugger warning - I hadn't
thought of that but it's obvious now that there could easily be a problem.

        Nick.











Path: ucivax!gateway
From: [e-mail]
Subject: MDEFs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 28 Sep 91 06:20:04 GMT

Does anyone know where the mDrawItemMsg, and mCalcItemMsg messages to
MDEFs are documented?  I can't seem to find anything, but I don't have
every tech note...
Thanks,
  --dave koziol
    u of michigan










Path: ucivax!gateway
From: [e-mail] (chapman alan)
Subject: GetResInfo Results??
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 29 Sep 91 00:17:38 GMT

The following code is extracted from an application I am writing.My question is simple.  Why does theType, as returned by GetResInfo,not work as an argument for CountResources or GetResource?  I have checked with the Think C Debugger (4.0.5) and the result of theGetResInfo call seems good, and each call to ResError returns zero.If I call CountResources with 'gMNU' rather than the result fromGetResInfo, it works fine but it defeats my purpose [the call to GetResource is not normally in this bit of code].Thanks for any help you can give,Alan [e-mail](){Handle    theHandle;int        theID, resErr, count;char    theType[4];Str255    name;theHandle = GetResource('gMNU', 20791);GetResInfo(theHandle, &theID, &theType, name);resErr = ResError();ReleaseResource(theHandle);resErr = ResError();count = CountResources(theType);resErr = ResError();theHandle = GetResource(theType, theID);resErr = ResError();}










Path: ucivax!gateway
From: [e-mail] (chapman alan)
Subject: GetResInfo Results Solved
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 29 Sep 91 00:54:07 GMT

OK I goofed, sorry for the wasted time.

I needed to declare theType as being of type ResType (which I had previously
done but had failed to pass it as &theType to GetResInfo).  I thought I had
done the right thing based on what the debugger gave back but too bad now, it's
fixed.

Thanks,
Alan.










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: WDEF's-as-objects: I'm *this* close, but...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 30 Sep 91 12:27:15 GMT

Well, I've pretty well got the WDEF thing working now - WDEF code resource
stub pointing into a generic dispatch routine and directing WDEF messages
to methods of a generic CWDEF Class. It all works fine, with one exception:
when the test application is in the background and is called upon to draw a
window frame, the frame is drawn through all the frontmost windows. It
behaves perfectly when the test application is the front layer.

The problem seems to be A5-World related. That would explain why it all
works fine in the foreground. I have to switch to the application's A5 to
get into the object and call methods and get at globals, of course. I tried
restoring the front app's A5 during the frame drawing, and that fixes the
problem (although it screws up any global and procedure access in the
object, of course, which is unacceptable). So, my guess is the following:
when a background app's WDEF is called to draw the frame, the front app's
A5 world contains the clipping information (possibly the visRgn of the WM
port). Swapping A5's loses the clipping information, so the frame draws
through the front windows.

Anybody have any suggestions? I can probably get it working with a little
more effort, but I'd quite like to know *why*, rather than risk having a
solution which breaks under System 7.0.0001.

In return, you get your name in the credits when I post the code. It's all
packaged up as a project, and requires minimal glue (one procedure call in
the actual application).

        Nick.











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: GetKeys Source Code
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 26 Sep 91 16:40:18 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 81
Date: 30 Sep 91 15:13:07 GMT

Here's a very ugly example of deciphering the KeyMap bits in THINK C.
It isn't anything special, but I thought that it may be a bit of help.

Enjoy,

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]

---------------- GetKeys.c ----------------
/*
 * GetKeys.c -- code frag that shows how to use the 'Old-style' KeyMap
 * structure, i.e., one that consists of an array of four longints.  This code
 * is appropriate for C 4.0 and Pascal 2.0.
 * Copyright ) 1990 Phil Shapiro, Symantec Corp.
 */

#include <stdio.h>
#include <console.h>
#include <string.h>

#include <EventMgr.h>


#define ENTRIES    128

/* hardcoded entries for the standard Mac II adb keyboard */

char *nameMap[ENTRIES] =
        { "A", "S", "D", "F", "H", "G", "Z", "X", "C", "V", 0,
          "B", "Q", "W", "E", "R", "Y", "T", "1", "2", "3", "4",
          "6", "5", "=", "9", "7", "-", "8", "0", "]", "O", "U",
          "[", "I", "P", "Return Key", "L", "J", "'", "K", ";", "\\",
          ",", "/", "N", "M", ".", "Tab Key", "Space Bar", "`",
          "Backspace Key", "Enter Key", "Escape Key", 0, "Command Key",
          "Shift Key", "Caps Lock Key", "Option Key", "Control Key", 0,
          0, 0, 0, 0, ". on Keypad", 0, "* on Keypad", 0, "+ on Keypad",
          0, "Clear Key", 0, 0, 0, "/ on Keypad", "Enter on Keypad",
          0, "- on Keypad", 0, 0, "= on Keypad", "0 on Keypad",
          "1 on Keypad", "2 on Keypad", "3 on Keypad", "4 on Keypad",
          "5 on Keypad", "6 on Keypad", "7 on Keypad", 0, "8 on Keypad",
          "9 on Keypad", 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
          0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, "Left Arrow",
          "Right Arrow", "Down Arrow", "Up Arrow", "keycode 0xff"};
    /* 128 entries */


void checkfor(KeyMap, short, char *);

void
checkfor(KeyMap map,short num, char *name)
{
    if (map.Key[num / 32] & ((1L << (num % 8)) << (24 - (8 * ((num % 32) / 8)))))
        if (name)
            printf("You pressed the %s.\n",name);
        else
            printf("You pressed keycode %#x.\n",num);
}

main()
{
    KeyMap    myMap;
    short i;

    printf("\n");
    do {
        GetKeys(&myMap);
        if (myMap.Key[0] || myMap.Key[1] || myMap.Key[2] || myMap.Key[3]) {
#ifdef DEBUG
/* print out the bits for each key */
            printf("%08lX\t%08lX\t%08lX\t%08lX\n", myMap.Key[0], myMap.Key[1],
                    myMap.Key[2], myMap.Key[3]);
#endif
            for (i = 0; i < ENTRIES; ++i)
                checkfor(myMap, i, nameMap[i]);
        }
    } while (!Button());
    FlushEvents(everyEvent,0);    /* trash the keyevents */
}










Path: ucivax!gateway
From: [e-mail]
Subject: Hello
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 30 Sep 91 21:45:54 GMT

Please add me to the THINK C mailing list.










Path: ucivax!gateway
From: [e-mail]
Subject: The Think C electronic mailing list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 5
Date: 30 Sep 91 23:22:14 GMT
X-Envelope-to: [e-mail]

Hello,
I am a owner of the THINK C compiler and would like to be on this list.
I am assuming this is the right place to ask. Thanks.

Hayden